科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道面向服务的分析与设计原理

面向服务的分析与设计原理

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

面向服务的体系结构(SOA)和 Web 服务的基本观念是成为我们日常语言的一部分,并可看作是适于设计现代企业应用程序的体系结构形式。

作者:Olaf Zimmermann 来源:论坛整理 2007年12月24日

关键字:

  • 评论
  • 分享微博
  • 分享邮件

在本页阅读全文(共5页)

OO 范式与面向服务 (SO) 范式

  OO 分析是一种非常强大且广为赞誉的方法,同样,SOAD 应该尽可能多地利用 OO 分析技术。要将 OO 分析成功地应用于 SOA 项目,您就必须一次分析多个系统。用况模型必须继续扮演重要的角色。然而,SOAD 必须主要是 流程,而不是 用户驱动的。因此,SOAD 需要 BPM 和用况建模活动之间的强链接。

  在 设计层,OO 的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造,其行为就像它们建模的真实世界的实体。例如,顾客 (Customer) 将有名称和联系信息,并且还可能有一个或多个与之相关的帐户对象。从 OO 的角度看,每件事情都是对象。

  OO的基本原则是:

  •   封装:软件对象就是包含模拟真实世界的对象的物理属性(数据)和功能(行为)的离散包。例如,帐户对象保持收支平衡并且包含平衡中的借贷机制。
  •   信息隐藏:结构良好的对象有简单的接口,并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是,您不需要详细了解汽车的工作原理就能够驾驶它。
  •   类和实例: 类是定义特定类型的软件对象具有什么类型的属性和行为的模板,而 实例是具有这些属性值的个别对象。创建类的新实例称为 实例化。利用生物学进行类比,人就是一个类。所有的人都具有一些属性,比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 HumanBeing 的实例,具有一些特定的身高、体重以及其他的属性值。类是一直存在的,而实例具有有限的生命周期。
  •   关联和继承:在 OO 中,表达类和对象之间的关联的能力是一个关键的概念;继承是关联的强形式,用于表达有关系:按照同样的方式,生物物种由这样的层次构成:界 (Kingdom)、门 (Phylum)、纲 (Class)、目 (Order)、科 (Family)、类 (Genus)、种 (Species)。我们常常发现软件对象的自然层次。例如,当您创建一个财务应用程序实体时,您可能需要构造像 经常帐户(CheckingAccount) 、 储蓄帐户(SavingsAccount) 和 贷款帐户(LoanAccount) 这样的对象。如果您看得更仔细一点(请参见 图 3),您将发现这些类共享许多属性,比如都有收支平衡帐户、借方帐户和贷方帐户等等

  图 3. UML 类继承示例

  UML 类继承示例

  与其重复定义和管理这些属性的代码,不如创建一个通用的 帐户(Account) 类,该类具有现金收支平衡并且可以处理借贷事务。所有其他的类都是这个 帐户(Account) 对象的专门形式。例如, 贷款帐户(LoanAccount) 将在零和某个约定的最大值之间具有负平衡,而 储蓄帐户(SavingsAccount) 将具有负平衡,并且将展示增加利息的行为,等等。

  消息传递:为了完成一些有用的工作,软件对象需要相互通信。它们通过相互发送消息来这样做。例如,假定我们想将 $1000 从经常帐户转到储蓄帐户,要达到此目的,可以将带有参数 $1000 的 借消息发送到 经常帐户(CheckingAccount) 实例,并且将相应的 贷消息发送到 储蓄帐户(SavingsAccount) 实例。当实例接收消息时,它执行相应的功能,称为 方法,它有与消息相同的名称。

  多态:这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如, 自由经常帐户(FreeCheckingAccount) 实例和 经常帐户(CheckingAccount) 实例将响应 借 ($100) 消息,但是 自由经常帐户(FreeCheckingAccount) 实例将正好 $1000 记入它的帐户平衡的借方,而 经常帐户(CheckingAccount) 实例将 $1000 加上交易费记入它的帐户平衡的借方。

  OO 支持应用程序分析、设计和开发的完整生命周期:

  OOAD试图找到最优的对象和最自然的类继承来实现它们。

  OO 开发集中于应用程序的渐进式开发,每次实现一个业务场景或用况。像 IBM WebSphere Studio Application Developer 这样的工具有助于开发人员快速地构造和测试 OO 应用程序。

  OO 运行时环境,例如由 Java 虚拟机提供的,提供应用程序服务(如垃圾收集(删除因使用它们的对象已经被丢弃而不再使用的资源))以及框架(如 J2EE)来为驻留在不同的服务器上的对象提供相互通信的机制。

  目前与 SO 有关的 OO 设计实践的主要问题在于,它的粒度级别集中在类级,对于业务服务建模来说,这样的抽象级别太低了。诸如继承这样的强关联产生了相关方之间一定程度的 紧耦合(因而具有依赖性)。与此相反,SO 范式试图通过 松耦合来促进灵活性和敏捷性。目前,在 SOA 中还没有服务 实例的跨平台继承支持和一流的表示法来避免需要处理服务生命周期维护管理问题(如远程垃圾收集)。

  这些考虑事项使 OO 难以与 SO 体系结构样式直接保持一致。然而,对于设计已定义的服务中的底层类和组件结构,OO 仍然是一种有价值的方法。此外,许多 OOAD 技术(例如类、责任、协作(CRC)卡)也可以用于服务建模(如果它们提升到更高层次的抽象的话)。在本文后面,我们将回过头来讨论这一点。

  图 4展示了可见性层次和 OO、 面向组件和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。

  图 4. 设计层次

  设计层次

  至于表示法,统一建模语言(Unified Modeling Language,UML)——通过一些附加的定型(Stereotype)和概要加以增强——自然成为 SOAD 的重要基础。

  在使用 Rational Unified Process (RUP)——被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面,使用 UML 模型具有首要价值。然而,RUP 以 OOAD 的原则为基础,因而使其不容易与 SOA 设计保持一致。从 RUP 的角度来看,系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外,这些组件还由逐渐减小到类级粒度的更小组件组成。相反,在 SOA 中,系统的体系结构通常包括满足普通 业务服务需要的无状态、全封装且自描述的服务组成,它更接近于映射到 BPM,如 图 5所示。

  图 5. SOAD 服务定义层次

  SOAD 服务定义层次

  这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点,而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件( 软件服务)设计的组件。

    • 评论
    • 分享微博
    • 分享邮件
    闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愪粙鏌ㄩ悢鍝勑㈤柣顓燁殜楠炴牕菐椤掆偓婵¤偐绱掗幇顓ф疁闁哄矉绻濆畷鍫曞煛娴i攱鐫忛梻浣告惈椤戝懘鏌婇敐澶婅摕闁哄浄绱曢悿鈧柣搴秵娴滅偞绂掗悙顒傜瘈婵炲牆鐏濋悘鐘绘煏閸喐鍊愮€殿喖顭峰鎾晬閸曨厽婢戦梺璇插嚱缂嶅棙绂嶉弽顓炵;闁规崘顕ч崘鈧銈嗘尪閸斿海绮欒箛娑欌拺閻犳亽鍔屽▍鎰版煙閸戙倖瀚�

    濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴濐潟閳ь剙鍊圭粋鎺斺偓锝庝簽閸旓箑顪冮妶鍡楀潑闁稿鎹囬弻娑㈡偄闁垮浠撮梺绯曟杹閸嬫挸顪冮妶鍡楀潑闁稿鎸剧槐鎾愁吋閸滃啳鍚Δ鐘靛仜閸燁偉鐏掗柣鐘叉穿鐏忔瑧绮i悙鐑樷拺鐟滅増甯掓禍浼存煕閹惧娲撮柟顔藉劤鐓ゆい蹇撴噳閹锋椽姊婚崒姘卞闁告娲熷畷濂稿Ψ閵壯勭叄婵犵數濮撮敃銈団偓姘煎弮瀹曪綀绠涢弮鍌滅槇婵犵數濮撮崐缁樻櫠濞戙垺鐓曢悗锝冨妼婵′粙鏌曢崶褍顏€殿喕绮欐俊姝岊槹闁逞屽墯鐢繝寮婚悢鍏煎癄濠㈣泛锕ュ▓濠氭⒑閸濆嫮鐏遍柛鐘崇墵楠炲啫饪伴崼婵堝幐闂佺ǹ鏈粙鎾广亹鐎n喗鐓熼幖娣€ゅḿ鎰箾閸欏顏堟偩濠靛牏鐭欓悹鎭掑妽濞堥箖姊洪崜鎻掍簼婵炲弶鐗犻幃鈥斥槈閵忥紕鍘遍柣蹇曞仜婢т粙鎯岀€n偆绠鹃柛顐ゅ枑閸婃劖鎱ㄦ繝鍕笡闁瑰嘲鎳愮划鐢碘偓锝庝簼閻d即姊绘担瑙勫仩闁告柨顑夊畷锟犲礃閼碱剚娈鹃梺闈涚箞閸婃洟宕橀埀顒€顪冮妶鍡楀闁稿骸宕惃顒勬⒒閸屾瑧鍔嶉悗绗涘懐鐭欓柟瀵稿Л閸嬫挸顫濋悡搴$睄閻庤娲戦崡鍐茬暦閸楃倣鐔兼⒐閹邦喚娉块梻鍌欑窔濞佳囨偋閸℃稑绠犻幖娣灪閸欏繑銇勯幒鍡椾壕闂佸疇顫夐崹鍧楀春閵夆晛骞㈡俊鐐插⒔閸戣绻濋悽闈浶為柛銊︽そ閺佸鏌ч懡銈呬沪濞e洤锕俊鍫曞川椤斿吋顏¢梻浣呵归鍛村磹閸︻厽宕叉繛鎴欏灩楠炪垺淇婇婵愬殭缁炬澘绉归弻锝嗘償閵忥絽顥濆銈忓閺佽顕g拠宸悑闁割偒鍋呴鍥⒒娴e憡鍟為柟鎼佺畺瀹曠増鎯旈…鎴炴櫔闂佹寧绻傞ˇ浠嬪极閸℃ぜ鈧帒顫濋濠傚闂佹椿鍘介〃鍡欐崲濞戙垹绠婚柡澶嬪灩閸斾即姊虹粙娆惧剱闁圭懓娲濠氭晲閸涱亝顫嶅┑鐐叉閸旀洜澹曢幎鑺モ拺闁告繂瀚﹢鎵磼鐎n偄鐏撮柛鈺冨仱楠炲鏁冮埀顒€顔忓┑鍥ヤ簻闁哄洨鍋為崳娲煃鐠囪鍔熺紒杈ㄦ崌瀹曟帒鈻庨幋婵嗩瀴婵$偑鍊戦崝宀勫箠濮椻偓楠炲棗鐣濋崟顐わ紲闂佺粯鍔欏ḿ褏绮婇敃鍌涚厵闁稿繗鍋愰弳姗€鏌涢弬璺ㄧ劯闁诡喚鍋ゅ畷褰掝敃閻樿京鐩庨梻浣告贡閸庛倝宕归悽鍓叉晜闁冲搫鎳忛崐鍨叏濮楀棗澧绘俊鎻掔秺閺屾洟宕惰椤忣厾鈧鍠曠划娆愪繆濮濆矈妲奸梺闈╃祷閸庡磭妲愰幘瀛樺缂佹稑顑呭▓顓炩攽閳藉棗浜濈紒璇茬墕椤曪絾绻濆顓炰簻缂佺偓濯芥ご鎼佸疾閿濆鍋℃繝濠傚暟鏁堥梺璇″枟閿曘垽骞婇悩娲绘晢闁稿本绮g槐鏌ユ⒑閸濆嫷妲搁柣妤€瀚板畷婵囨償閿濆洣绗夐梺缁樺姉閸庛倝鎮″☉銏″€堕柣鎰硾琚氶梺鍝ュУ閿曘垽寮婚埄鍐╁闁荤喐婢橀~鎺楁倵鐟欏嫭绀堥柛鐘崇墵閵嗕礁顫滈埀顒勫箖閳哄懏鎯炴い鎰╁€濋幏濠氭⒒閸屾艾鈧嘲霉閸パ呮殾闁割煈鍋呴崣蹇涙煙閹澘袚闁抽攱姊婚埀顒€绠嶉崕閬嵥囬鐐插瀭闁稿瞼鍋為悡銏′繆椤栨粌鐨戠紒杈ㄥ哺閺屻劌鈹戦崱鈺傂︾紓浣插亾閻庯綆鍋佹禍婊堟煛瀹ュ啫濡块柍钘夘槹缁绘盯宕奸悢铏圭厜濠殿喖锕ㄥ▍锝呪槈閻㈢ǹ宸濇い鏂惧嫎閳ь剚鍔曢—鍐Χ鎼粹€茬凹濠电偠灏欓崰鏍х暦濞差亜鐒垫い鎺嶉檷娴滄粓鏌熼崫鍕棞濞存粓绠栧娲箰鎼淬垻鈹涙繝纰樷偓铏悙閸楅亶鏌熼悧鍫熺凡缂侇偄绉归弻娑㈩敃閿濆洨鐣煎銈嗘尰濡炶棄顫忛搹鍦<婵☆垰鎼~宀勬倵濞堝灝娅橀柛鎾寸懆閻忓啴姊洪崨濠佺繁闁哥姵宀稿畷銏ゅ箹娴e厜鎷洪梺鍛婃尰瑜板啯绂嶆禒瀣厱閻庯綆浜滈顓㈡煙椤旀枻鑰块柡浣稿暣瀹曟帒鈽夊顒€绠為梻浣筋嚙閸戠晫绱為崱娑樼;闁糕剝蓱濞呯姵銇勯幒鎴濃偓鑽ゅ婵傚憡鐓曢悘鐐插⒔閳藉绱掑锕€娲﹂悡娆撴煟閻斿憡绶叉い蹇e弮閺岀喖鎮℃惔銏g闂佺懓寮堕幐鍐茬暦閻斿吋顥堟繛鎴炵懄閻濓繝姊婚崒姘偓鎼佸磹妞嬪海鐭嗗〒姘e亾妤犵偞鐗犻、鏇㈠Χ閸屾矮澹曞┑顔矫畷顒勫储鐎电硶鍋撶憴鍕缂傚秴锕濠氬幢濡ゅ﹤鎮戦梺鍛婁緱閸ㄧ晫妲愰柆宥嗙厽閹艰揪绱曢悾顓㈡煕鎼淬劋鎲鹃挊婵喢归崗鍏肩稇缁炬崘娉曢埀顒€绠嶉崕閬嵥囨导瀛樺亗闁哄洢鍨洪悡娑㈡煕閵夛絽鍔氬┑锛勫帶椤儻顧侀柛銊ゅ嵆濠€渚€姊虹紒妯撳湱绮旈鈧、鏃堝醇閻旇櫣鏆㈤梻鍌氬€烽悞锔锯偓绗涘懏宕查柛灞绢嚤濞戞鏃堝川椤撶姴骞掗梻浣告惈濞层垽宕瑰ú顏呭亗闁告劦浜濋崰鎰節婵犲倻澧曠紒鈧崼鐔稿弿婵☆垱瀵х涵楣冩煢閸愵亜鏋涢柡灞炬礃缁绘稖顦查悗姘卞厴瀹曟垿濡搁埡鍌楁嫼缂傚倷鐒﹂敋濠殿喖娲﹂妵鍕即閵娿儱绫嶉梺绯曟杺閸ㄨ棄顕i幘顔碱潊闁炽儲鏋奸崑鎾绘偨閸涘﹦鍙嗗┑鐘绘涧濡鍩€椤掑倹鍤€闁宠绉瑰畷鍫曞Ω閿濆嫮鐩庨梻濠庡亜濞诧妇绮欓幇鏉跨疅濡わ絽鍟悡娑㈡倶閻愰潧浜剧紒鈧€n兘鍋撶憴鍕濞存粌鐖奸妴浣割潨閳ь剟骞冮姀锛勯檮濠㈣泛顦辨径锟�

    重磅专题
    往期文章
    最新文章